home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-07-22 | 41.2 KB | 1,120 lines |
-
-
- Internet Engineering Task Force Fumio Teraoka
- INTERNET-DRAFT SonyCSL
- Keisuke Uehara
- University of Electro-Comm.
- July 1993
-
-
- The Virtual Network Protocol for Host Mobility
-
-
-
- Status of this Memo
-
- This document is an Internet Draft. Internet Drafts are working
- documents of the Internet Engineering Task Force (IETF), its Areas,
- and its Working Groups. Note that other groups may also distribute
- working documents as Internet Drafts.
-
- Internet Drafts are draft documents valid for a maximum of six
- months. Internet Drafts may be updated, replaced, or obsoleted by
- other documents at any time. It is not appropriate to use Internet
- Drafts as reference material or to cite them other than as a
- ``working draft'' or ``work in progress.''
-
- This document has been presented to, and is being evaluated by,
- the "Mobile IP" working group of the IETF. This document is being
- published as an Internet Draft in order to allow the general IETF
- community the opportunity to gain a wider understanding of the issues
- involved in mobile IP routing, as well as to understand the specific
- solution proposed in this document. This document has not received
- any formal endorsement from the Mobile IP working group.
-
- Abstract
-
- This memo describes the general virtual network protocol that
- provides the transport layer with host migration transparency. This
- protocol is based on the concept of a `virtual network' and the
- `propagating cache method'[1]. Basically, this protocol can be
- applied to any connectionless network layer protocol. This memo also
- describes two virtual network protocols: `VIP' (Virtual Internet
- Protocol) and `ISO-VIP'. The former is derived from IP, the network
- layer protocol of Internet, while the latter is derived from CLNP,
- the connectionless-mode network layer protocol of ISO.
-
-
- 1. Overview of the Protocol
-
- Host migration transparency can be defined as an environment in
-
-
-
- Expires: January 1994 [Page 1]
-
- INTERNET-DRAFT VIP July 1993
-
-
- which a user is unaware of physical migration of hosts, or an
- application program is unaware of physical migration of its peers.
- According to the protocol layering based on the OSI reference model,
- the network layer should provide host migration transparency. There
- are two key services in the network layer for host migration
- transparency: `migration transparent host addressing' and `migration
- transparent connectionless-mode communication'[1]. The `concept of a
- virtual network' was introduced to provide the former, while the
- `propagating cache method' was proposed to achieve the latter.
-
- According to the virtual network concept, each host is logically
- connected to the same virtual network called the `home network' even
- if it physically moves. Therefore, each host has an immutable
- network address, which can be thought of as a `host identifier'.
- Such addresses are called `virtual network addresses' or `VN-
- addresses'. Since the network layer provides the transport layer
- with VN-addresses, host migration becomes transparent to transport
- and higher layers.
-
- To deliver packets, a host must have another network address
- which indicates physical location of the host. Such addresses are
- called `physical network addresses' or `PN-addresses'. Since the
- transport layer specifies hosts by their VN-addresses, the network
- layer must resolve VN-addresses into corresponding PN-addresses. To
- incorporate the function for such address resolution in the OSI
- reference model, the network layer is divided into two sublayers: the
- `virtual network sublayer' (VN-sublayer) and the `physical network
- sublayer' (PN-sublayer). The VN-sublayer resolves VN-addresses into
- PN-addresses, and then the PN-sublayer delivers packets by using PN-
- addresses.
-
- The VN-sublayer employs the `propagating cache method' for
- efficient address resolution. In this method, each host/router has a
- cache called the `Address Mapping Table (AMT)' to store the relation
- between VN-addresses and PN-addresses. When a host/router receives a
- packet, it caches the relation between the VN/PN-addresses into its
- AMT. Upon transmission, the source host specifies the VN-address of
- the destination host as the destination PN-address if it has no AMT
- entry for the destination host. Such a packet heads for the home
- network of the destination host and address resolution is executed by
- either an intermediate router or a router in the home network of the
- destination host. Once this source host receives a reply packet from
- the destination host, it creates the AMT entry for the destination
- host and it can execute address resolution at the next transmission
- time.
-
-
-
-
-
-
- Expires: January 1994 [Page 2]
-
- INTERNET-DRAFT VIP July 1993
-
-
- 2. Terminology
-
- In this memo, the following terms are used.
-
- o virtual network addresses (VN-addresses): migration independent
- host identifiers in the network layer. Each host has a VN-
- address. Transport and higher layers use VN-addresses to
- specify hosts. Since VN-addresses are immutable, transport and
- higher layers can indicate mobile hosts no matter where they
- are connected.
-
- o physical network addresses (PN-addresses): migration dependent
- host identifiers indicating host location. The PN-address of a
- mobile host may change in compliance with host's location. In
- other words, when a host moves, it must be assigned a temporary
- PN-address by a certain mechanism such as DHCP[2] in IP
- networks and the extended ES-IS protocol[3] in CLNP networks.
-
- o home network: the subnetwork indicated by the VN-address of a
- mobile host.
-
- o address mapping table (AMT): a table held at each host or
- router in the network. An AMT consists of entries, each of
- which holds the relation between a VN-address and a PN-address
- of a mobile host. There are two types of AMT entries:
-
- - home AMT entries: AMT entries that are created in the home
- network of a mobile host.
-
- - cache AMT entries: AMT entries that are created in the
- subnetworks other than the home network of a mobile host.
-
- o address resolution: processing in which a VN-address is
- resolved into the corresponding PN-address with the assistance
- of an AMT.
-
- o address resolver: a router that executes address resolution.
- Address resolvers are classified into three types:
-
- - primary address resolver (for a mobile host): an address
- resolver that is connected to the home network of the mobile
- host. A primary resolver advertises the reachability to the
- mobile hosts. All primary resolvers for the mobile host
- always hold its most recent AMT entry unless errors such as
- network partitioning occur in the network.
-
- - secondary address resolver (for a mobile host): an address
- resolver that is connected to a subnetwork other than the
-
-
-
- Expires: January 1994 [Page 3]
-
- INTERNET-DRAFT VIP July 1993
-
-
- home network of the mobile host. Secondary resolvers may
- hold the most recent AMT entry for the host.
-
- - temporary proxy (for a mobile host): secondary address
- resolvers in the subnetwork to which the mobile host was
- previously connected. A temporary proxy holds the most
- recent AMT entry for the mobile host until the entry times
- out unless errors occur in the network.
-
- o family hosts (for an address resolver): hosts for which an
- address resolver is a primary address resolver.
-
- o foreign hosts (for an address resolver): hosts for which an
- address resolver is not a primary address resolver.
-
- 3. The General Virtual Network Protocol
-
- This section defines the general `virtual network protocol (VN-
- protocol)' to support host mobility, which is basically applicable to
- any connectionless-mode network protocol.
-
- 3.1. Packet Headers
-
- There are two types of packet header formats, the data packet
- and the control packet. The header of the data packet consists of
- ten fields as follows:
-
- o flags:
-
- - control/data = data
-
- - authentication: if this flag is on, this packet has
- authentication data.
-
- - address resolution only at primary: if this flag is on, only
- primary resolvers for the destination host execute address
- resolution.
-
- - AMT update only at primary: if this flag is on, only primary
- resolvers for the source host create or update its AMT
- entry.
-
- o source VN-address, PN-address, and address pair version number
-
- o destination VN-address, PN-address, and address pair version
- number
-
- o holding time: the initial value of the holding time field of an
-
-
-
- Expires: January 1994 [Page 4]
-
- INTERNET-DRAFT VIP July 1993
-
-
- AMT entry when it is created or updated by this packet.
-
- o resolver PN-address: the PN-address of the address resolver
- that executed address resolution.
-
- o (option) authentication data
-
-
- The header of the control packet consists of ten fields as
- follows:
-
- o flags:
-
- - control/data = control
-
- - authentication: if this flag is on, this packet has
- authentication data.
-
- - AMT update only at primary: if this flag is on, only primary
- resolvers for the target system update the AMT entry.
-
- - AMT entry creation/invalidation (CAmt/InvAmt): this flag
- specifies the type of AMT entry manipulation, i.e.
- creation/update (CAmt) or invalidation (InvAmt).
-
- - broadcast InvAmt: if this flag is on, when a router has an
- obsolete AMT entry, it broadcast an `InvAmt' packet to all
- the subnetworks to which it is connected.
-
- o source VN-address, PN-address, and address version number
-
- o destination PN-address
-
- o target system VN-address, PN-address, address version number,
- and holding time
-
- o (option) authentication data
-
- 3.2. AMT Entry
-
- A general AMT entry consists of five fields as follows:
-
- o VN-address: the key of this entry.
-
- o PN-address: the requested value.
-
- o address version number: the version number of the VN-
- address/PN-address pair of this entry.
-
-
-
- Expires: January 1994 [Page 5]
-
- INTERNET-DRAFT VIP July 1993
-
-
- o flags:
-
- - use/free: the entry is in use or free.
-
- - valid/invalid: the entry holds valid information or invalid
- information.
-
- - home/cache: the entry is a home AMT entry or a cache AMT
- entry.
-
- - local/not-local: the mobile host indicated by this entry is
- connected to the same segment or not.
-
- o holding time: the value of this field is decremented by one for
- a certain time interval. When the value becomes zero, this
- entry is deleted.
-
-
- An AMT entry has one of three states: `free', `valid', or
- `invalid'. In the `free' state, an AMT entry is not allocated to any
- mobile host. In the `valid' state, when a router relays a packet
- having older destination address information than this AMT entry, it
- executes address resolution for the destination host. In the
- `invalid' state, when a system receives a packet having older
- destination address information than this AMT entry, it transmits an
- `InvAmt' packet to the host specified by the resolver PN-address
- field or the target system PN-address field of the packet. Figure 1
- shows the state transition diagram of an AMT entry.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires: January 1994 [Page 6]
-
- INTERNET-DRAFT VIP July 1993
-
-
- receive CAmt +---------+
- or data packet| |
- +----------| Free |
- | +------->| |<--------+
- | | +---------+ |
- | | | time out
- | | time out |
- | | | receive old data packet
- V | receive new CAmt or | -----------------------
- +---------+ new data packet +---------+ send InvAmt
- | |<--------------------| |<--+
- | Valid | | Invalid | |
- | |-------------------->| |---+
- +---------+ receive new InvAmt +---------+
- | ^ | ^
- | | | |
- +-----+ +-----+
- receive CAmt or receive old CAmt or
- data packet InvAmt
-
- Figure 1: AMT entry state transition diagram
-
-
- +--------------+ <PR> primary
- | home network | resolver
- CAmt | | CAmt
- (3)+--------|---- <PR> <---|-------+ <SR> secondary
- | +--------------+ | resolver
- InvAmt| InvAmt InvAmt | InvAmt
- <-----<SR>----->(4) (2)<----<SR>----> <TP> temporary
- | | proxy
- | |(1) (secondary
- +---------V--------+ move +--------|--------+ resolver)
- | <TP> - -|- - - - - - -|- - > <MH> |
- | | | | <MH> mobile
- | previous network | | current network | host
- +------------------+ +-----------------+
-
- Figure 2: Host connection
-
- 3.3. Host Migration
-
- Figure 2 depicts a packet flow when a mobile host is connected
- to a subnetwork.
-
- 1. The mobile host transmits a `CAmt' packet to its home network.
- On the transmission path of this `CAmt' packet, intermediate
- routers create or update the AMT entry for the mobile host
-
-
-
- Expires: January 1994 [Page 7]
-
- INTERNET-DRAFT VIP July 1993
-
-
- unless the flags field of the `CAmt' packet prohibits caching,
- i.e. such intermediate routers become secondary address
- resolver for the mobile host. During connecting to a
- subnetwork, the mobile host continues to transmit a `CAmt'
- packet for a certain time interval.
-
- 2. If an intermediate router holds an obsolete AMT entry for the
- mobile host and the flags field of the `CAmt' packet indicates
- `broadcast InvAmt', it broadcasts an `InvAmt' packet to all
- the subnetworks to which the router is connected in order to
- invalidate obsolete entries which might remain on other
- routers. When a router receives such an `InvAmt' packet, if
- it holds an obsolete AMT entry, it invalidates the entry and
- also broadcasts the `InvAmt' packet. If it holds a newer AMT
- entry or does not have the corresponding entry, it discards
- the `InvAmt' packet.
-
- 3. When a primary address resolver for the mobile host receives
- this `CAmt' packet, it also creates or updates the AMT entry
- for the mobile host. If it holds an obsolete AMT entry for
- the mobile host, it transmits another `CAmt' packet to the
- network specified by the obsolete AMT entry. After routers in
- the previous network receive this `CAmt' packet, they hold the
- most recent AMT entry for the mobile host until it times out,
- i.e. each router in the previous subnetwork becomes a
- `temporary proxy' for the mobile host.
-
- 4. On the path of the `CAmt' packet transmitted by a primary
- address resolver, intermediate routers create or update the
- AMT entry for the mobile host unless the flags field of the
- `CAmt' packet prohibits caching, i.e. they become secondary
- address resolvers for the mobile host. If a router holds an
- obsolete AMT entry for the mobile host and the flags field of
- the `CAmt' packet indicates `broadcast InvAmt', the router
- broadcasts an `InvAmt' packet to all the subnetworks to which
- the router is connected in order to invalidate obsolete AMT
- entries which might remain on other routers.
-
-
- Figure 3 depicts a packet flow when a mobile host disconnects
- from a subnetwork or is powered off.
-
- 1. The mobile host may transmit an `InvAmt' packet to its home
- network.
-
- 2. On the path of the `InvAmt' packet, if an intermediate router
- has an obsolete AMT entry for the mobile host and the flags
- field of the `InvAmt' packet indicates `broadcast InvAmt', the
-
-
-
- Expires: January 1994 [Page 8]
-
- INTERNET-DRAFT VIP July 1993
-
-
- router broadcasts another `InvAmt' packet to all the
- subnetworks to which it is connected.
-
- 3. When a primary address resolver for the mobile host receives
- the `InvAmt' packet, if it has an obsolete AMT entry for the
- host and the flags field of the `InvAmt' packet indicates
- `broadcast InvAmt', the primary address resolver broadcasts
- another `InvAmt' packet to all the subnetworks to which it is
- connected.
-
-
- ^ ^ ^ <PR> primary
- (1)|disconnect or | | resolver
- power off |InvAmt (3)|InvAmt
- +--------|--------+ | +------|-------+ <SR> secondary
- | <MH> -----|-----<SR>-----|---> <PR> --->| resolver
- | InvAmt| |Inv | |InvAmt |
- | | (2)| Amt | V | <MH> mobile
- | current network | V | home network | host
- +-----------------+ +--------------+
-
- Figure 3: Host disconnection or power off
-
-
- +--------------+ <PR> primary
- | home network | resolver
- | |
- +----------|-----<PR> | <SR> secondary
- | +------^-------+ resolver
- | |
- | +--<SR> | <TP> temporary
- +---|-----+ | | | +----------+ proxy
- | v | V | | | |
- | <MH> <--|---+----------------|----+ | <OR> obsolete
- | | ^ | | | | | AMT entry
- | current | | | | <OR>--|-> <TP> |
- | network | | | | | | | <S> source
- +---------+ <S> <S> <S> <S> | previous | host
- (a) (b) (c) (d) | network |
- +----------+
-
- Figure 4: Data communication
-
-
- 3.4. Data Communication
-
- Figure 4 depicts four types of packet flows for data
- communication.
-
-
-
- Expires: January 1994 [Page 9]
-
- INTERNET-DRAFT VIP July 1993
-
-
- (a) If the source host has the AMT entry for the destination host,
- it executes address resolution at transmission time. The
- packet will traverse the optimal route.
-
- (b) If the source host does not have the AMT entry for the
- destination host, it sets the VN-address of the destination
- host to the destination PN-address field. The packet heads
- for the home network of the destination host. If an
- intermediate router holds an AMT entry for the destination
- host, it executes address resolution and forwards the packet.
-
- (c) A primary address resolver ultimately receives the packet
- heading for the home network of the destination host. When it
- receives the packet, it executes address resolution and
- forwards the packet.
-
- (d) A router which holds an obsolete AMT entry for the destination
- host executes address resolution for the packet heading for
- the home network of the destination host. The packet is
- forwarded to the previous network of the destination host. A
- temporary proxy of the destination host in the previous
- network executes address resolution and forwards the packet to
- the correct location. Since the packet holds the PN-address
- of the address resolver that executed incorrect address
- resolution, the temporary proxy transmits an `InvAmt' packet
- to it in order to invalidate the obsolete AMT entry.
-
-
- When the source host receives a reply packet from the
- destination host, it creates or updates the AMT entry for the
- destination host. Therefore, the source host can hereafter execute
- address resolution at transmission time.
-
- 3.5. Packet Conversion
-
- If a host does not have the functions for the VN-protocol, it
- transmits conventional network layer packets. When a router relays
- such a packet, if it has the AMT entry for the destination host of
- the packet, it converts the packet into a VN-protocol packet and
- forwards it. In the worst case, such a packet reaches a primary
- address resolver for the destination host and is converted into a
- VN-protocol packet. When such a host receives a VN-protocol packet,
- although it will ignore the header of the VN-sublayer, it correctly
- recognizes the VN-address of the source host.
-
- 4. VIP: Virtual Internet Protocol
-
- VIP (Virtual Internet Protocol) is derived from IP by applying
-
-
-
- Expires: January 1994 [Page 10]
-
- INTERNET-DRAFT VIP July 1993
-
-
- the general VN-protocol defined in Section 3. `VIP addresses' are
- introduced as VN-addresses in the VN-protocol, while IP addresses are
- thought of as PN-addresses. The IP option fields of the IP header is
- used for the VIP header. The size of the VIP header is 28 octets if
- authentication data is not included. Table 1 shows the
- correspondence of the VN-protocol to VIP. Figures 5-(a), 5-(b), and
- 6 depict the packet formats of VIP and the format of an AMT entry for
- VIP respectively. In Figure 5-(a) and 5-(b), the beginning 20 octets
- indicate the IP header and the remaining octets are the VIP header as
- an IP option. Note that the IP header includes the source `VIP'
- address and the VIP header includes the source `IP' address.
-
-
- Table 1:Correspondence of the VN-protocol to VIP
-
- VN-protocol | VIP
- ------------------|--------------------------------------------------
- VN-address | VIP address
- |
- PN-address | IP address
- |
- home network | the subnetwork indicated by the network number
- | of the VIP address
- |
- primary address | routers connected to the home network of a mobile
- resolvers | host
- |
- secondary address | routers connected to the subnetworks other than
- resolvers | the home network of a mobile host
- |
- temporary proxy | routers connected to the previous network of a
- | mobile host
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires: January 1994 [Page 11]
-
- INTERNET-DRAFT VIP July 1993
-
-
- 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ver. | IHL | TOS | Total Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Identification |Flags| Fragment Offset |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | TTL | Protocol | Header Checksum |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Source VIP Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Destination IP Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Option Type | Option Length | Ver. |unused | Flags |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Source IP Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Destination VIP Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Source Address Version |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Destination Address Version |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Holding Time |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Resolving System IP Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Authentication Data |
- = =
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 5-(a): Data packet
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires: January 1994 [Page 12]
-
- INTERNET-DRAFT VIP July 1993
-
-
- 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ver. | IHL | TOS | Total Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Identification |Flags| Fragment Offset |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | TTL | Protocol | Header Checksum |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Source VIP Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Destination IP Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Option Type | Option Length | Ver. |unused | Flags |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Source IP Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Source Address Version |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Target System VIP Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Target System IP Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Target System Address Version |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Target System Holding Time |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Authentication Data |
- = =
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 5-(b): Control packet header
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires: January 1994 [Page 13]
-
- INTERNET-DRAFT VIP July 1993
-
-
- 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | VIP Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | IP Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Address Version |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Flags | reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | | | |
- | | | +-- use(1)/free(0)
- | | +---- valid(1)/invalid(0)
- | +------ home(1)/not-home(0)
- +-------- local(1)/not-local(0)
-
- Figure 6: AMT entry for VIP
-
- Figure 7 shows a packet flow when a host is connected to a
- subnetwork. The differences between the packet flow in the VN-
- protocol and VIP are:
-
- o when a primary address resolver receives a `CAmt' packet from a
- family host, it broadcasts another `CAmt' packet in the home
- network in order to update the AMT entry on the other primary
- address resolvers in the home network.
-
- o when a router receives a `CAmt' from a foreign host that was
- previously connected to the same subnetwork, it broadcasts the
- `CAmt' in the subnetwork in order to update the AMT entry on
- the other routers in the subnetwork.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires: January 1994 [Page 14]
-
- INTERNET-DRAFT VIP July 1993
-
-
- +-----------------+ <HR> home
- |<HR> ^ <HR>| router
- | (3)|CAmt |
- (4) | | | <R> router
- +--------|----- <HR> <-----|-------+
- (5) | +-----------------+ (2) | <MH> mobile
- <----<R>----> home network <----<R>----> host
- InvAmt| InvAmt|
- |CAmt (1)|CAmt
- +-------|--------+ +-------|-------+
- | <--<R>--> | | <R> |
- | CAmt|(6) | move | | |
- | V - -|- - - - - - - - -|- - > <MH> |
- |<R> <R>| |<R> <R>|
- +----------------+ +---------------+
- previous network current network
-
- Figure 7: Packet flow upon host migration in VIP
-
-
- 5. ISO-VIP: Extended CLNP for Mobile Host
-
- ISO-VIP is derived from CLNP (Connectionless-mode Network
- Protocol)[4] by applying the VN-protocol defined in Section 3. It is
- assumed that ES-IS[5] and IS-IS[6] are used as routing information
- exchange protocols. In IS-IS, an NSAP address consists of three
- portions: area address, ID, and SEL. An area address is unique in a
- routing domain, an ID is unique in an area, and a SEL indicates the
- entity which is to receive the PDU. Although NSAP addresses remain
- unchanged when an ES moves within an area according to the IS-IS
- model, a temporary PN-address is assigned to an ES when it migrates
- to another subnetwork even within an area in ISO-VIP. Table 2 shows
- the correspondence of the VN-protocol to ISO-VIP. Figures 8 and 9
- show the header formats of PDU and the AMT entry formats for ISO-VIP
- respectively.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires: January 1994 [Page 15]
-
- INTERNET-DRAFT VIP July 1993
-
-
- Table 2: Correspondence of the VN-protocol to ISO-VIP
-
- VN-protocol | ISO-VIP
- ------------------|-------------------------------------------------
- VN-address | V-NSAP address (virtual NSAP address) or
- | V-NET (virtual network entity title)
- |
- PN-address | NSAP address of NET
- |
- home network | the subnetwork to which the designated level1-IS
- | that advertises the connectivity to the ES
- | is connected
- |
- primary address | the level1-IS that advertises the connectivity
- resolver | to the ES
- |
- secondary address | ISs other than primary address resolver
- resolver |
- |
- temporary proxy | the designated level1-IS in the previous
- | subnetwork of an ES
-
-
- octets
- +--------------------------------------+
- | Destination Address Length Indicator | 1
- +--------------------------------------+
- | Destination Address | dst addr len
- +--------------------------------------+
- | Source Address Length Indicator | 1
- +--------------------------------------+
- | Source Virtual Address | src addr len
- +--------------------------------------+
- (a) Address Part
-
- Figure 8-(a): ISO-VIP packet header: Address Part
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires: January 1994 [Page 16]
-
- INTERNET-DRAFT VIP July 1993
-
-
- octets
- +--------------------------------------+
- | Param Code = ISO-VIP | 1
- +--------------------------------------+
- | Param Len = variable | 1
- +--------------------------------------+
- | Flags | 1
- +--------------------------------------+
- | Destination Virtual Address | dst addr len
- +--------------------------------------+
- | Destination Address Version | 4
- +--------------------------------------+
- | Source Address | src addr len
- +--------------------------------------+
- | Source Address Version | 4
- +--------------------------------------+
- | Holding Time | 4
- +--------------------------------------+
- | Resolver Address Length | 1
- +--------------------------------------+
- | Resolver Address | addr len
- +--------------------------------------+
- | Authentication | n
- +--------------------------------------+
- (b) Option part: ISO-VIP Data
-
- Figure 8-(b): ISO-VIP packet header: Option Part: ISO-VIP Data
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires: January 1994 [Page 17]
-
- INTERNET-DRAFT VIP July 1993
-
-
- octets
- +--------------------------------------+
- | Param Code = ISO-VIP | 1
- +--------------------------------------+
- | Param Len = variable | 1
- +--------------------------------------+
- | Flags | 1
- +--------------------------------------+
- | Source Address | src addr len
- +--------------------------------------+
- | Source Address Version | 4
- +--------------------------------------+
- | Target System Address Length | 1
- +--------------------------------------+
- | Target System Virtual Address | addr len
- +--------------------------------------+
- | Target System Address | addr len
- +--------------------------------------+
- | Target System Address Version | 4
- +--------------------------------------+
- | Target System Holding Time | 4
- +--------------------------------------+
- | Authentication | n
- +--------------------------------------+
- (c) Option part: ISO-VIP Control
-
- Figure 8-(c): ISO-VIP packet header: Option Part: ISO-VIP Control
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires: January 1994 [Page 18]
-
- INTERNET-DRAFT VIP July 1993
-
-
- octets
- +--------------------------+
- | Flags | 1
- +--------------------------+
- | Holding Time | 4
- +--------------------------+
- | Address Version Number | 4
- +--------------------------+
- | ID Length Indicator | 1
- +--------------------------+
- | ID | id len
- +--------------------------+
- | Address Length Indicator | 1
- +--------------------------+
- | Address | addr len
- +--------------------------+
- (a) AMT entry
-
- +-+-+-+-+-+-+-+-+
- | Flags |
- +-+-+-+-+-+-+-+-+
- | | |
- | | +- use(1)/free(0)
- | +--- valid(1)/invalid(0)
- +----- home(1)/not-home(0)
- (b) Flags
-
- Figure 9: AMT entry for ISO-VIP
-
- Author's Address:
-
- o Fumio Teraoka
- Sony Computer Science Laboratory Inc.
- 3-14-13 Higashigotanda, Shinagawa-ku, Tokyo 141, Japan.
- Phone: +81-3-5448-4380
- Email: tera@csl.sony.co.jp
-
- o Keisuke Uehara
- University of Electro-Communications.
- 1-5-1 Chofugaoka, Chofu, Tokyo 182, Japan.
- Phone: +81-424-83-2161, ext. 4122
- Email: kei@cs.uec.ac.jp
-
- References
-
- [1] F. Teraoka, Y. Yokote, and M. Tokoro. "A Network Architecture
- Providing Host Migration Transparency," in Proc. of SIGCOMM'91,
- Sep. 1991.
-
-
-
- Expires: January 1994 [Page 19]
-
- INTERNET-DRAFT VIP July 1993
-
-
- [2] R. Droms. "Dynamic Host Configuration Protocol," Internet Draft,
- Dec. 1992.
-
- [3] ISO. "Information processing systems - Telecommunications and
- information exchange between systems - End system to Intermediate
- system routeing exchange protocol for use in conjunction with the
- Protocol for providing the connectionless-mode network service
- (ISO 8473) - Amendment 1: Dynamic discovery of OSI NSAP Addresses
- by End System," ISO 9542, 1988.
-
- [4] ISO. "Information processing systems - Data communications -
- Protocol for providing the connectionless-mode network service,"
- ISO 8473, 1988.
-
- [5] ISO. "Information processing systems - Telecommunications and
- information exchange between systems - End system to Intermediate
- system routeing exchange protocol for use in conjunction with the
- Protocol for providing the connectionless-mode network service
- (ISO 8473)," ISO 9542, 1988.
-
- [6] ISO. "Information processing systems - Telecommunications and
- information exchange between systems - Intermediate system to
- Intermediate system intra-domain routeing exchange protocol for
- use in conjunction with the Protocol for providing the
- connectionless-mode network service (ISO 8473)," ISO 10589, 1992.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires: January 1994 [Page 20]
-
-